home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Turnbull China Bikeride
/
Turnbull China Bikeride - Disc 1.iso
/
HENSA
/
NETWORK
/
FREENET.ARC
/
!FreeNet
/
Docs
/
Setup
< prev
next >
Wrap
Text File
|
1996-10-13
|
9KB
|
210 lines
Configuring the FreeNet TCP/IP Stack
(C) Tom Hughes 1995
0. Copyright
The FreeNet module and application and the tools and documentation
that go with them are all copyright. They are however released as
freeware subject to certain terms and conditions. These are described
in the file named 'Licence' which should have accompanied this
document.
1. Overview
Configuring FreeNet is a relatively simple process which requires the
editing of two scripts; one which starts up FreeNet and one which
shuts it down again.
The first of these two scripts, !FreeUser.Startup, begins by loading
the necessary modules and then configures the interfaces and routing
ready for use. The second kills off all the modules, and returns the
system to its normal state.
The remainder of this document details the various commands used in
the startup file to configure parts of the system. This, together with
the example provided with FreeNet should be sufficient to configure
FreeNet without any problems. Hopefully a future release of FreeNet
will include a desktop application to do this configuration.
2. Installing additional hardware drivers
If you wish to use a hardware driver other than those supplied with
FreeNet, you will to place the appropriate module in !FreeUser.Drivers
and then add a line to the startup script to load this driver.
You can of course store the module somewhere else if you wish. The
named directory is simply provided as a convenient place where you may
wish to place it. Note that this is not the same as !FreeNet.Drivers
which is the directory used to hold the supplied drivers.
The startup script will also need to be modified to load this driver
by adding an appropriate 'RMRun' command. If the driver has been
installed in !FreeUser.Drivers, you can use the FreeNet: path to
locate the driver, as in this example:
RMRun FreeNet:Drivers.SLIPdriver
This command would load a driver named SLIPdriver which was in either
!FreeUser.Drivers (for user installed drivers) or !FreeNet.Drivers
(for FreeNet supplied drivers).
3. Configuring interfaces
The first thing you will need to do after loading FreeNet and your
chosen hardware driver is to configure the interfaces that you wish to
use. You should note that some drivers (including the supplied SLIP
driver) will need some configuration before this can be done, and you
should consult the documentation supplied with the driver for the
relevant information.
Once this has been done, the ifconfig command can be used to inform
FreeNet that the interface exists, and to set various relevant
options. The syntax of this command is as follows:
ifconfig <interface> [inet <local-address> [<remote-address>]]
[netmask <mask>] [broadcast <address>] [arp] [up|down]
[revarp]
Here, you should give the address that you wish to assign to the
interface as <local-address> and for point-to-point links like SLIP or
PPP connections, the address of the other end of the link should be
given for <remote-address>. Alternatively, specify revarp to cause
the address to be found by querying a server using RevARP.
If the interface is on a network that has been subnetted, you will
need to specify an appropriate value for the netmask. If you don't
know what this should be, your sysadmin should be able to tell you.
For broadcast networks such as ethernet, you can specify the address
to be used for broadcast packets on that network. This will default to
the standard 255.255.255.255 unless otherwise specified. You will also
need to include the arp flag when configuring an interface on a
broadcast network, to specify that the ARP protocol should be used to
resolve addresses on the local network.
Finally, the interface is marked up or down by including the keyword
up or down in the ifconfig command line. An interface that is marked
down will not be used to transmit packets, so this can be used to
temporarily disable an interface.
To summarise all this, consider the following examples of ifconfig
commands. The first example configures a SLIP interface with a local
address of 158.152.40.58 which talks to 158.152.1.222 at the other end
of the link:
ifconfig sl0 inet 158.152.40.58 158.152.1.222 up
An ethernet interface (ethernet interfaces are often ea0 or eb0, but
check your card's documentation to be sure) would be configured as
follows, where the host 163.162.5.45 is on subnet 163.162.5.0 of a
class B network whose number is 163.162.0.0, giving a netmask of
0xffffff00.
ifconfig eb0 inet 163.162.5.45 netmask 0xffffff00 arp up
This interface could be temporarily removed from operation using the
command:
ifconfig eb0 down
It would then be returned to use using the following:
ifconfig eb0 up
Once you have configured your interfaces, you should be able to obtain
a list of available interfaces using the command 'netstat -i'.
4. Configuring the routing tables
Having a system with properly configured interfaces is not much help
unless TCP/IP is told which packets to route through which interfaces,
and what address those packets should be addressed through. When an
interface is configured, a single route will be added to the routing
tables for that interface, which will be sufficient to reach some
local hosts.
In the case of point-to-point links like SLIP, a route will have been
added for the remote address at the other end of the link. This will
allow you to talk to that machine but to nothing else. For interfaces
on broadcast networks such as ethernet, things are slightly better as
there will be a route to all hosts on the local (sub)net. You should
be able to use 'netstat -r' to see what routes are currently in the
routing tables.
Adding and removing routes is done using the route command. The add
form of the command has the following syntax:
route add <destination>[/<bits>] <gateway> <metric>
Where <destination> is the address of a host or network that can be
reached via the host identified by <gateway>. The <metric> parameter
is an indication of the efficiency of that route compared to others to
the same destination.
Normally, the destination address will be examined to see whether the
host part of the address is zero. If it is, the route will be treated
as a route to a network, otherwise it will be treated as a route to a
specific host. This can be overridden by specifying the number of bits
of the destination address which should be treated as significant.
Where the destination is on a directly attached network, you should
specify your own address as the gateway, and give a metric of zero. In
other cases, the gateway should be the address of a machine on a
directly connected network that knows how to reach the specified
destination, and the metric should be non-zero.
As an example, consider the following, which tells the machine from
our previous example (163.162.5.45) how to reach machines on the
subnet 163.162.12.0 of the local network:
route add 163.162.12.0 163.162.5.1 1
This says that addresses on subnet 163.162.12.0 can be reached by
sending packets to 163.162.5.1 which is on the directly connected
subnet (163.162.5.0) and knows how to reach the other subnet. By
comparison, the following tells the same machine how to reach the
local subnet (this would normally be done automatically by ifconfig of
course):
route add 163.162.5.0 163.162.5.45 0
One final, and vital point about adding routes is the setting of the
default route. This is done by specifing 'default' as the destination,
and this route will be used for any destination which does not have an
explicit route in the routing tables.
Deleteing routes is accomplished by using the following, alternative
syntax of the route command:
route delete <destination>[/<bits>] <gateway>
Where the <destination> and <gateway> parameters are those given to
the original 'route add', and which can be displayed by using the
command 'netstat -r' to examine the routing tables.
5. Checking your configuration
Once you have configured your interfaces and routing tables, and
verified them using 'netstat -i' and 'netstat -r', you should be ready
to go.
At this point, you will probably want to use the ping utility to
ensure that your machine can see other machines. In its simplest form,
you can simply type 'ping <address>' to test whether your machine can
see a particular remote machine. Full documentation for the ping tool
can be found in the appropriate file.
Another useful utility is traceroute which will attempt to work out
what route a packet would follow to reach a given address. This is
useful in attempting to solve routing problems, and can be used by
entering 'traceroute <address>'. Full documentation of other options
for this tool are documented seperately.
Other forms of the netstat command which you may also find useful
include 'netstat' which lists all sockets which are currently in
existence, 'netstat -s' which gives a large number of statistics about
the number and type of packets which have passed throught the TCP/IP
stack, and 'netstat -m' which reports how many memory buffers ar
currently free for use.